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SECTION 1 
GENERAL INFORMATION 



1.1 INTRODUCTION 



This document contains information about the DNCS Nucleus 

product, release 1.3.0, that is not contained elsewhere in the 

standard documentation associated with the object installation 
kit. 

The subjects that are discussed in this document are special 
features or considerations that may be important for the proper 
Installation and operation of the object package. 



1.2 DNCS 1.3 OVERVIEW 



The following paragraphs provide an overview of topics discussed 
in greater detail throughout this document. 



1.2.1 NEW FEATURES AND ENHANCEMENTS. 

Updates to the DNCS Nucleus since the last release are as 
follows ; 

'1. Gateway/client support. This release provides 
transparent SNA and X.25 service to client systems that 
are connected on the same Ethernet LAN as the Gateway. 
The DNIO communications package allows distribution of 
DNCS commands and procedures to the client for user 
friendly and transparent access to Gateway services. 
Prior to this release, the user was required to do a 
"network logon" to the Gateway before executing any 
DNCS command. With this release, the network logon is 
no longer required. Part of the DNCS user interface 
can be distributed to the client systems such that all 
commands can be initiated at the client. All of the 
commands in the Nucleus command groups /NUC, /DNET, 
/SVQ, and /SITES have been revised to operate in both 
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gateway/ client and single computer environments. 

2. Revised object installation procedures that describe 
how to install DNCS software on a client computer. The 
use of a Gateway User ID and Password is also described 
since various functions asscociated with DNCS require 
the initiation of a job at the gateway. 

3. DNCS Operation Guide revised and reissued to include 
information on gateway/client operation, SVQ utility 
improvements, and revised command prompt descriptions 
for XDNCS , TDNCS, CFQ, HOSTQST, LSITE, and CSDT. The 
CI command !D TERMS has a new parameter <LOC> which 
allows display of additional information concerning SNA 
Emulator user status. 

4. All patches from previous release incorporated into 
source . 



1.2.2 MIGRATION FROM DNCS 1.2. 

DNCS 1.3 must be installed on a DNOS 1.2.1 or later system 
volume. DNCS 1.3 is not compatible with earlier versions of 
DNOS. 

The DNCS configurations created by the DNCS 1.2 generation 
utility are compatible with DNCS 1.3, and may be used as input 
configurations to DNCS 1.3. You must execute the XDGU procedure 
for each existing configuration and then follow the object 
installation procedures defined for DNCS 1.3 because there are 
changes in the data structures created for DNCS 1.3. 



1.2.3 RESOURCE REQUIREMENTS. 

Section 2 provides the information necessary to determine how 
much disk space and memory a particular DNCS configuration will 
require . 

1.2.4 SYSTEM GENERATION CONSIDERATIONS. 

Section 3 details several items concerning DNCS configuration 
definition and operation of XDGU that should be reviewed prior to 
generating a DNCS configuration. 
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1.2.5 SPECIAL CONFIGURATION CONSIDERATIONS. 

Section 4 addresses several special requirements, such as running 
DNCS and 3780 from the same CP503, that should be reviewed prior 
to generating a DNCS configuration. 

1.2.6 DNOS COMMUNICATIONS SUBSYSTEM CONSIDERATIONS. 

Section 5 contains several Items concerning specific 

communications hardware interface modules, and the standard 

utilities that should be reviewed when planning a new DNOS/DNCS 
system. 

1.2.7 KNOWN PROBLEMS. 

Section 6 documents additional messages that do not appear 
elsewhere in DNCS documentation, as well as certain known 
operational restrictions and problems. 

1.2.8 PATCHES AND PATCH PROCEDURES. 

Section 7 discusses how to obtain and apply patches that are made 
available after initial installation of this DNCS release. 

1.2.9 PROBLEM ISOLATION AND REPORTING. 

Section 8 discusses the* steps necessary to isolate a DNCS system 
failure, collect the required data, and report this information 
to your customer representative for resolution. 
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SECTION 2 
RESOURCE REQUIREMENTS 



2.1 DISK SPACE REQUIREMENTS 

The following table summarizes the approximate disk space 
requirements for the DNCS Nucleus and its add-on parts. These 
requirements fall into three general areas: object installation 
parts, configuration dependent parts, and execution parts. The 
figures are estimates and will vary depending on the number of 
sectors/ADU of the disk and configuration parameters. Generally, 
the larger the sectors/ADU the more disk space required, due to 
disk allocation on an ADU basis. Also, the more configurable 
resources defined in DNCS the more disk space required. The ADU 
size in the following table is based on 864 bytes/ADU with a 
physical record size of 768 bytes. 

gateway client 

disk resident disk resident 
Object Installation Parts space (ADUs) space (ADUs) 

DCFWO (Nucleus) 

DCEMO (SNA add-on) 

DCRFTO (RFT add-on) 

DC9140 (914 add-on) 

Configuration Dependent Parts 

Typical DNCS system 2500-3000 

Execution Parts 



4100 


900 


1000 


200 



Commands, program files, 1100-1700 400-500 

and logs 

Note that the configuration dependent parts are on a per system 
basis; each new configuration requires approximately 2500-3000 
more ADUs. 
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2.2 MEMORY REQUIREMENTS 

In that DNCS is highly configurable, its memory requirements vary 
widely from one configuration to the next. Therefore, a method 
is presented to give the user an idea of the relative size of a 
given configuration. 

2.2.1 MEMORY WORKSHEET. 

The following worksheet will give a rough estimate of how much 
memory DNCS will require. 
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COMPONENT MEMORY RESIDENT NON-RESIDENT 

NUCLEUS: Base 61700 61700 51000 51000 

SDLC circuit (each) -300 1000 

MAXREADS x 400 



LAP circuit (each) 400 1500 

128 byte packets, 

MAXREADS x 380 

256-1024 byte, 

MAXREADS x (.... + 120) 

(.... is packet size) 

SNA SUPPORT: Base 50400 

PU 100 

LU 10 

CIPC circuit (each) 300 

RESOURCES x 60 

Active EM3278 station (first) 20500 

(second and subsequent) 7200 

Active EM3287 task (first) 12900 

(second and subsequent) 4400 

X.25 SUPPORT: Base 46500 

SNA interface 9300 

DNIO interface 7900 

RFT circuit 300 

MAXREADS x 900 

NIO circuit 300 

MAXREADS ____ x 7 00 

Active RFT task 35000 

TOTAL: resident: non-resident 
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2.3 IMPACT OF DNCS ON DNOS SYSTEM TABLE AREA 



The DNOS system table area is impacted both directly and 
indirectly by the DNOS communication subsystem and DNCS 
communication requirements. Directly by inclusion of the 
Physical Device Tables (PDTs) for each communication channel. 
Indirectly by increasing the DNOS system root, which limits the 
maximum allowed system table size. The following equation may be 
used to calculate the impact on system table area (in bytes) for 
support of DNCS communications. All variables are specified 
during the generation of DNOS with DNCS communication support as 
described in the DNCS Nucleus Object Installation Guide . 

1032 + 484*(no. of DEVICES with BOARD TYPE of DIPC) 

+ 10*(sum of all SESSIONS for all DEVICES with BOARD TYPE of 

DIPC) 
+ 426*(no. of CHANNELS with PROTOCOL of SDLC) 
+ 554*(no. of CHANNELS with PROTOCOL of LAP) 
+ 104*(no. of DEVICES with BOARD TYPE of CP503) 
+ 210*(no. of CHANNELS for all DEVICES with BOARD TYPE of 

CP503 and PROTOCOL of LAP, SDLC, or COMA) 
+ 162*(no. of DEVICES with BOARD TYPE of CP501 or CP502) 
+ 218*(no. of DEVICES with BOARD. TYPE of CI421) 
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SECTION 3 
DNCS GENERATION CONSIDERATIONS 



3.1 DNCS SYSTEM GENERATION 



The following paragraphs describe DNCS System Generation 
(DNCSGEN) features and limitations relating to the current 
release . 



3.1.1 DNCS GENERATION UTILITY (XDGU). 

XDGU presents a user friendly interface for entering required 
configuration parameters. The following information may be 
helpful in preventing operational problems that may occur when 
trying to use XDGU. 

1. While in XDGU, it is possible to modify a circuit which 
supports resources, such as CIPC circuits, to a circuit 
which does not support resources, such as SDLC 
circuits. This is an error condition. A circuit so 
defined should be deleted and re-added. 

2. The 'print' key under XDGU works if TIFORM is installed 
on the user's system. If TIFORM is not installed, the 
'print' key does not work and the following message 
appears: 'NTERNAL ERROR CODE >0041 xxxxx' . 



3.1.2 VERIFY DEVICE CONFIGURATION PROCESS. 

The verify process is not intended to find all possible errors 
that might be entered when creating a particular DNCSGEN 
configuration. In particular, the following is a list of errors 
you might make during DNCSGEN that the verification will not 
catch : 

1. Pooled LU assignments for resources of type SVQ, PTR, 
or KSR. These resource types normally have dedicated 
logical units rather than logical units assigned from a 
pool because it is usually desirable to have messages 

2239933-9901** 3-1 



DNCS Generation Considerations DNCS Nucleus Release Information 



sent to a particular logical unit address to always be 
sent to the same resource. 

2. A circuit referencing a port which is defined on the 
wrong type board to support the required function, 
i.e., an IPC circuit attached to a port which is 
defined on a FCCC board, or a SDLC circuit attached to 
a port which is defined on a VIRTUAL board. 



3-2 
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SECTION 4 
SPECIAL CONFIGURATION CONSIDERATIONS 

4.1 MODIFYING THE SIZE OF THE DNCS BUFFER POOL 

Due to the dynamic requirements of the DNCS buffer pool, the XDGU 
process may not, in some cases, cause a large enough buffer pool 
to be allocated at DNCS startup time. Therefore, with some 
configurations, DNCS may display one or more occurrences of 
either of the following messages: 

DNCS0514 E MAXREADS ON CIRCUIT xx REDUCED TO yy 

DNCSxxOl E RSVBID: GET BUFFER FAILURE; L/C=aaaa, P=bbbb 

If either of these messages occur, terminate DNCS and increase 
the total number of buffers available to the system in one of the 
following ways: 

1. Text edit the file . S$DGU$ .conf igname . S . SCTDEF . Near 
the end of the file, locate the following statement: 

NUMBID DATA nnn 

where: nnn is a 3 digit decimal number 
Increase the value nnn by 20% and rerun ALDC, and PIDC. 
OR 



2. Locate the address of BUFHDR+2 in the linkmap 
. S$DGU. conf igname. LINKMAP .DNCSSCT and patch (using MPI) 
the word at this address to a larger value (20%) and 
restart DNCS. 
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4.2 SHARING A CP503 BETWEEN DNCS AND OTHER SOFTWARE PACKAGES 



When a CP503 (FCCC) communications interface module is specified 
in the DNCS generation process, the resulting DNCS configuration 
assumes that DNCS will have exclusive use of the CP503. That is, 
XDNCS (and TDNCS) will issue a master reset to the CP503. 
Additionally, during normal operation DNCS wil^ issue a master 
reset to the CP503 whenever a CI command is issued to stop or 
restart the DNCS board associated with the CP503. A master reset 
issued to the CP503 causes all functions on that board to cease 
immediately, and all downloaded protocol code to be discarded. 

Therefore, if other communications software packages, such as 
3780, RTS, or ICS are to use one or more ports on a CP503 
concurrently with DNCS, the generated DNCS configuration needs to 
be altered as follows: 

1. After XDGU is completed, but before doing ALDC, text 
edit the file ,S$DGU$ .conf igname . S . PDCDEF. Near the 
end of the file, locate the following set of statements 
that corresponds to the CP503 that is to be shared: 

BOARD 
PORTaa PORT 0,>bb,0,CMxx 

where: aa is a 2 digit decimal DNCS port number 

bb is the LUNO specified in XDGU for this port 

CMxx is the DNOS communications device, name of 

a port on the CP503 to be shared. 

Change the statement "BOARD 0" to "BOARD 1". This 
change will prevent DNCS from issuing a master reset to 
this CP503 whenever a CI stop or restart board command 
is issued to this board. 

The following items are side effects of making the 
above change: 

a. DNCS will not load any CP503 firmware patches to 
this board; therefore, they must be loaded prior 
to DNCS startup via the CDL common utility. 

b. It will now be impossible to stop a port on this 
board that is in the disconnected "DISCN" state. 

c. DNCS will not be able to automatically restart a 
port on this board if certain I/O operations to 
that port fail to complete properly. 
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2. Run the ALDC and PIDC procedures. 

3. After PIDC completes, text edit the file DNCSASYN in 
the DNCS command directory (the DNCS command directory 
is normally .S$CMDS). Locate the following statement: 



.SYN $$RSTBRD = "( CMxx , CMyy , . . . ) " 



This statement defines the list of CMxx device names to 
which master resets (via CRSET) are to be issued during 
the execution of the XDNCS and TDNCS procedures. 
Delete the CMxx device from this list that corresponds 
to the CP503 that is to be shared. Note that this step 
must be repeated following each exeuction of PIDC with 
the option INSTALL=YES. 

4. The XDNCS command should now be placed in .S$ISBTCH 
following the CDL of the firmware patches for this 
CP503. 



4.3 USING LAP NRZI ON CP502 

DNCS now supports LAP NRZI on the CP502 (the CP502 supplies the 

clocking) , but this option cannot be directly requested during 

XDGU. Instead, the following steps must be taken to enable this 
support : 

1. After XDGU is completed, but before doing ALDC, text 
edit the file . S$DGU$ .conf igname . S .PDCDEF. Locate the 
following circuit statement that is connected to the 
CP502 that is to run LAP NRZI: 

CIRCnn CIRC PORTxx , 4 ,0 ,LAP , , , 278 , 278 , 7 , 134 ,0 , , 7 , 7 , 3*2 , 10 

where: nn is a 2 digit decimal DNCS circuit number 

xx points to the port statement that, in turn, 
contains the CMxx DNOS communications device 
name of the desired CP502. 

Change the character string "LAP" to "LAPN". 

2. Run ALDC and PIDC procedures. 
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SECTION 5 
DNOS COMMUNICATIONS SUBSYSTEM CONSIDERATIONS 

5.1 DNOS COMMUNICATIONS SUBSYSTEM 



The following paragraphs describe communication subsystem 
features relating to the current release. 



5.1.1 COMMUNICATIONS INTERFACE MODULES. 

The supported communication interface modules are CP501 (BCAIM), 
CP502 (X.21 BCAIM), CP503 (FCCC), and CI421 (ALPHA). 

5.1.1.1 CP503 - FOUR CHANNEL COMMUNICATIONS CONTROLLER. (FCCC). 
The FCCC occupies one full slot in the 990 chassis. Refer to the 
FCCC Installation and Operation Manual (part number 2263878-9701) 
for a detailed description of the board and its appropriate slot 
position and interrupt level. The recommended interrupt level 
and TILINE address is interrupt 8 and TILINE address >F900. The 
TILINE address is switch selected on the FCCC board and is 
independent of the slot it occupies in the chassis. 



NOTE 

Use communications interface cable, part 
number 946117-0001 or -0002, when connecting 
an FCCC channel to an external modem. If a 
full 24 pin cable is used, the FCCC channel's 
receive circuitry will be disabled, even with 
pin 24 cut. 



5.1.1.2 CP501 - BIT-ORIENTED/ CHARACTER-ORIENTED ASYNCHRONOUS 
INTERFACE MODULE. (BCAIM). The BCAIM occupies one-half slot in 
the 990 chassis. Refer to the BCAIM Installation and Operation 
Manual (part number 2263883-9701) for a detailed description of 
the board and its appropriate slot position and interrupt level. 
The recommended interrupt level is 7. 
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NOTE 

When ordering the BCAIM communications 
Interface Kit (part number 2 303091-0002), the 
kit will include either cable 2303070-0002 or 
2303079-0002. 



5.1.1.3 CP502 - X.21 BIT-ORIENTED/CHARACTER-ORIENTED 
ASYNCHRONOUS INTERFACE MODULE. (X.21 BCAIM). The X.21 BCAIM 
occupies one-half slot in the 990 chassis. Refer to the X.21 
BCAIM Installation and Operation Manual (part number 2263886- 
9701) for a detailed description of the board and its appropriate 
slot position and interrupt level. The recommended interrupt 
level is 7. This is the only board that supports NRZI mode via 
synchronous modems . 



NOTE 

When ordering the X.21 BCAIM Communications 
Interface Kit (part number 2265184-0002), the 
kit will include either cable 2303070-0002 or 
2303079-0002. 



5.1.1.4 CI421 - TWO CHANNEL COMMUNICATIONS BOARD. (ALPHA). The 
ALPHA is mounted piggyback on the Business System 300 terminal 
control board. Refer to the Business System 300 Operator's Guide 
(part number 2533318-9701) for information related to this 
device . 



5.1.2 USING A COMBINATION OF COMMUNICATIONS INTERFACE MODULES. 

In systems where a combination of the above interface modules are 

present, the BCAIM or X.21 BCAIM should have a higher interrupt 

level than the FCCC. The higher the interrupt level, the lower 

its numerical value. In general, the load placed upon the CPU is 

directly related to the number of interrupts. Interrupt levels, 

interrupt rates, and the number of devices being supported are 

all factors to be considered when configuring an operating 
system. 
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5.1.3 USE WITH BELL 201B OR SYNTEK MODEMS. 

The BELL data set interface (part number 946104-0002) does not 
operate properly with the BELL 201B modem or SYNTEK modems unless 
the cable (part number 946117-0001) is modified by cutting the 
wire connected to pin 24 of the male cable connector. Mark the 
cable to indicate this modification. 



5.1.4 DNOS COMMON COMMUNICATIONS UTILITIES. 

The DNCS Nucleus uses the Reset Communications Device (CRSET) to 
reset the FCCC and BCAIM devices. Refer to the Dnos Common 
Communications Utilities Guide , part number 2308783-9701 for an 
explanation of utility commands, log messages, and error codes. 



5.1.5 CP503 VERIFICATION OF OPERATION. 

The Coram Device List Memory ( CLM) utility command may be used to 
test the CP503. Enter the CP503 CMxx device name and the 
starting address 09A. If the CLM command executes properly, the 
version of the firmware will be displayed. This version should 
be 80.354 or later. Display of this information proves that the 
CP503 is processing interrupts correctly, thus eliminating a mis- 
match between the address/ interrupt on the board and the system 
configuration. If problems persist, the CP503 should be tested 
using diagnostics. 

5.1.6 CP501/CP502 VERIFICATION OF TYPE/ OPERATION . 

The CLM utility command may be used to test the CP501/CP502 and 
to determine whether the board is, in fact, a CP501 or CP502 
without visually checking the board. Enter the CMxx device name 
for the board and the starting address of 096. If the CLM 
command executes properly, the second word displayed will be 0002 
for CP501 and 0003 for CP502. Display of this information proves 
that the board is processing interrupts correctly, and is 
installed/generated at the correct CRU address. If the CLM 
fails, the board should be tested using diagnostics. 
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SECTION 6 

KNOWN PROBLEMS 

This section documents known problems that may be encountered in 
installing and operating the DNCS Nucleus object package. 



6.1 SOFTWARE 



1. When certain communication I/O operations are not 
completed within 10 seconds, DNCS automatically 
(without operator intervention) issues a master reset 
to the board. This reset mechanism is used to force 
completion of the I/O requests so that a failure of one 
communication interface module will not cause DNCS to 
"hang", thereby not servicing other active DNCS 
functions. This automatic board reset, however, is not 
issued to an FCCC (CP503) when it is marked as shared 
by non-DNCS protocols (see Section 4 for an explanation 
of this option) . 

2. XDNCS and TDNCS procedures issue a reset to the CP503 
(FCCC) which clears all downloaded code on the board. 
If other communications software packages are to share 
the same CP503, it is recommended that you follow the 
steps in section 4 concerning "sharing of CP503 between 
DNCS and other communications software packages". 

3. STR 10376 - Password protection of DNCS commands is 
available only thru a DNCS CI command. However, this 
specification is not permanent and must be re-entered 
whenever the system is rebooted. Optional patch 1750 
in PATNUC allows permanent enabling of password 
protection and specification of the password value. 

4. STR 18856 - Under certain peak SVQ data I/O traffic 
conditions, QHOST transactions may be interrupted by an 
IPC error 06 and force the SVQ host queue server 
(SVQHST) to abnormally terminate. Patch P3843 corrects 
this problem. 

5. STR 18884 - Under certain data traffic and 
communications link conditions, SVQHST has been 
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observed to dequeue unprocessed transactions from the 
service queue file as though they had been processed. 
If entries are on the service queue file and SVQHST 
loses its session (the. PU goes inactive), the host 
reconnect sequence may get disrupted, when SVQHST 
attempts to send transactions after the PU becomes 
active. A series of DNCSOO 13- messages may occur in the 
host trace file in association with this problem. Any 
unprocessed transactions must be" reentered on the 
service queue. 



6.2 DOCUMENTATION 

1. The DNCS Nucleus Object Installation Guide (paragraph 
5.5) specifies that when installing a new DNCS 
configuration, it is necessary to reboot the system 
before executing XDNCS. If the system is not rebooted, 
the memory segment allocated for the old PDCT task may 
not be large enough to hold the new PDCT put into 
execution by DNCSINIT. This causes PDCT to go to end 
action. However, the reboot forces the correct segment 
length. 

2. The SBLU resource referenced in the DNCS System 
Generation Manual is reserved for internal use. 
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SECTION 7 
PATCHES AND PATCH PROCEDURES 



7.1 PATCH UPDATE PROCEDURE 



Patches are maintained by Texas Instruments and are available to 
customers from two sources - Customer Support Line and Patch 
Update Service. The Customer Support Line is able to provide 
patches on an as needed basis over the telephone or by 
communications link. Call (5 12)-250-7407 to get the latest patch 
files. Periodically, Texas Instruments will ship all current 
patches for the DNOS system family software to customers on the 
subscription service. Refer to the DNOS Products Patch Update 
Service Release Information for a list of the latest patches. In 
both cases, a detailed explanation will be provided on how to 
apply the patches to your system. 

It is recommended that you call the Customer Support Line to get 
the latest patches prior to installation of the product. 



7.2 APPLYING" PATCHES RECEIVED AT A LATER DATE 



When you receive patch updates, instructions are included in the 
update package which describe how to copy the patch files to your 
master media. 
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SECTION 8 

PROBLEM ISOLATION AND REPORTING 

The following steps should b"e taken to isolate a DNCS system 
failure, collect the necessary data, and report the problem to 
your customer representative for resolution. 



8.1 DNCS SYSTEM "HANG" 



There are many internal integrity checks made by DNCS during 
normal execution. If one of these checks determines the internal 
integrity of DNCS has been compromised, the DNCS job will "hang" 
with all DNCS tasks suspended, except DNCSCLOK. To verify that 
an intentional DNCS "hang" condition exists, do the following: 

1. Execute the DNOS XOI command. 

2. Execute the XJM command. 

3. Page forward (Fl) until XJM displays the DNCS job 
status . 

4. Observe the job status for* several seconds; if all 
DNCSxxxx tasks are in state 06 (except DNCSCLOK) and 
remain in state 06, then either a task has taken 
abnormal end action, or an automatic "hang" condition 
has been forced. 

5. Execute the DNOS QOI command. 

If it is determined that a DNCS "hang" condition exists, do the 
following steps to collect data about the condition for later 
analysis by your customer representative: 

1. Create a "PROBLEM" directory to be used to collect 
pertinent data files. 

2. Log off the current SCI session and log onto the DNCS 
job, USER ID=<DNCS USER ID> , PASSCODE=<DNCS PASSC0DE>, 
JOB NAME=DNCS, RECONNECT=YES (where DNCS USER ID and 
DNCS PASSCODE are the values defined during the PIDC 
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installation process). Note that you may need to 
modify your terminal status via the MTS command in 
order to RECONNECT. 

3. Execute the LJ command with JOB NAME=DNCS, TASK 
INFO=YES, LISTING ACCESS NAME=<PR0BLEM> .LJ 

4. Execute the XJM command again; look for the DNCSxxxx 
task that is causing the "hang" condition as follows: 

a. Look for any DNCSxxxx task in state 06 at PC 0052 
or 0058; if any found, this is the task causing 
the hang; else 

b. Look at DNCSCLOK status; if not present, or in 
state 06 and remains in state 06, this is the 
task causing the "hang"; else 

c. Look for a DNCSxxxx task (other than DNCSCLOK) 
that is in state 06 at a PC that is not 084C, but 
the PC is less than 26D8; if found, this is the 
task causing the "hang"; else 

d. Look for DNCSPDCT task, if it is in state 06 at 
PC 4972, it is the task causing the "hang". 

5. Note the RUN ID of the task causing the "hang". 

6. Execute the LM command with RUN ID-ID of task causing 
"hang". STARTING ADDRESS-0, NUMBER OF BYTES-0FFFE, 
LISTING ACCESS NAME=»<PR0BLEM> .LMid where "id" is value 
of RUN ID. 

7. Log off the DNCS job and log back on under a different 
job. 

8. Execute the TDNCS command to terminate DNCS. 

9. Execute the CC command with INPUT ACCESS 
NAME=.S$DNCS.LOG, OUTPUT ACCESS NAME=<PROBLEM> . DNCSLOG . 

10. Execute the CC command with INPUT ACCESS NAME=.S$L0G1 
OUTPUT ACCESS NAME=<PROBLEM> . DN0SL0G1 . 

11. Execute the CC command with INPUT ACCESS NAME=.S$L0G2 
OUTPUT ACCESS NAME=<PR0BLEM> . DN0SL0G2 . 

12. Document, to the best of your ability, what functions 
were being performed by DNCS just prior to the "hang". 
For example, "just entered the CI command DISPLAY 
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BOARDS, then the command DISPLAY CIRCUITS; the DISPLAY 
CIRCUITS never completed". 

13. If desired at this time, execute the XDNCS command. 

14. Collect linkmaps and other configuration data as 
outlined in the next paragraph. 



8.2 DNOS SYSTEM CRASH 

If a system crash occurs, refer to the DNOS Messages and Codes 
Reference Manual for an explanation of the crash code shown on 
the programmer panel of the CPU. To conduct a crash analysis, 
refer to the DNOS Systems Programmers Guide . If the crash is 
not understandable, or if the crash continues to occur, or if the 
crash was forced, you may want to send information to your 
customer representative for analysis. Before sending the crash 
file, be sure that it was created large enough to contain the 
entire system image. 

If your software was supplied to you directly by Texas 
Instruments and you are sending the information to Texas 
Instruments for analysis, please send the following information 
on either magnetic tape, diskettes, or some other disk media: 

1. The .S$CRASH file from the system crash saved according 
to procedures described in the DNOS Messages and Codes 
Reference Manual . 

2. The DNOS system linkmaps (found in files SYSMAP, 
IOUMAP, DMMAP) , system configuration (found in file 
CONFIG), communication subsystem linkmaps (found in 
files DMAPCOMA, DMAPCMNS, DMAPSDLC, DMAPLAP , CMAPCSWS), 
and communication subsystem configuration (found in 
file LSTCFDSR) for the system in use at the time of the 
crash. If these linkmaps are on the running system, 
they can be found in the directory . S$ SGU$ . <sys t em 
name) . 

3. The DNCS Nucleus linkmaps found in the directory <dncs 
generation volume) . S$DGU$ .<conf iguration> .LINKMAP for 
the system in use at the time of the crash. 

4. The DNCS system configuration found in the file <dncs 
generation volume) . S$DGU$ ^configuration) .TEXTCONF for 
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the system in use at the time of the crash. 

5. The DNCS configurable task definition files found in 
the directory <dncs generation volume) . S$DGU$ . 
<conf iguration>.LIST. 

6. A text file with information about the system activity 
at the time of the crash. 

7. A current listing of your software configuration, the 
output from the List Software Configuration (LSC) 
command * 

8. The DNCS and RFT log files. 
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